Browsersikkerhed: En dybdegående gennemgang af Content Security Policy (CSP)

I nutidens webmiljø er sikkerhed altafgørende. Hjemmesider står over for en konstant strøm af potentielle angreb, herunder cross-site scripting (XSS), datainjektion og clickjacking. Et af de mest effektive forsvar mod disse trusler er Content Security Policy (CSP). Denne artikel giver en omfattende guide til CSP, hvor vi udforsker dens fordele, implementering og bedste praksis for at sikre dine webapplikationer.

Hvad er Content Security Policy (CSP)?

Content Security Policy (CSP) er et ekstra sikkerhedslag, der hjælper med at opdage og afbøde visse typer angreb, herunder Cross Site Scripting (XSS) og datainjektionsangreb. Disse angreb bruges til alt fra datatyveri til ødelæggelse af sider og distribution af malware.

CSP er i bund og grund en hvidliste, der fortæller browseren, hvilke indholdskilder der betragtes som sikre at indlæse. Ved at definere en streng politik instruerer du browseren til at ignorere alt indhold fra kilder, der ikke er eksplicit godkendt, hvilket effektivt neutraliserer mange XSS-angreb.

Hvorfor er CSP vigtigt?

CSP tilbyder flere afgørende fordele:

• Afbøder XSS-angreb: Ved at kontrollere de kilder, hvorfra browseren kan indlæse indhold, reducerer CSP markant risikoen for XSS-angreb.
• Reducerer clickjacking-sårbarheder: CSP kan hjælpe med at forhindre clickjacking-angreb ved at kontrollere, hvordan en hjemmeside kan blive indrammet (framed).
• Gennemtvinger HTTPS: CSP kan sikre, at alle ressourcer indlæses over HTTPS, hvilket forhindrer man-in-the-middle-angreb.
• Reducerer virkningen af upålideligt indhold: Selvom upålideligt indhold på en eller anden måde bliver injiceret på din side, kan CSP forhindre det i at udføre skadelige scripts.
• Giver rapportering: CSP kan konfigureres til at rapportere overtrædelser, hvilket giver dig mulighed for at overvåge og finjustere din sikkerhedspolitik.

Hvordan virker CSP

CSP virker ved at tilføje en HTTP-response-header eller et <meta>-tag til dine websider. Denne header/tag definerer en politik, som browseren skal håndhæve, når den indlæser ressourcer. Politikken består af en række direktiver, hvor hvert direktiv specificerer de tilladte kilder for en bestemt type ressource (f.eks. scripts, stylesheets, billeder, skrifttyper).

Browseren håndhæver derefter denne politik ved at blokere alle ressourcer, der ikke matcher de tilladte kilder. Når en overtrædelse sker, kan browseren valgfrit rapportere den til en specificeret URL.

CSP-direktiver: En omfattende oversigt

CSP-direktiver er kernen i politikken og definerer de tilladte kilder for forskellige typer ressourcer. Her er en oversigt over de mest almindelige og essentielle direktiver:

• default-src: Dette direktiv definerer standardkilden for alle ressourcetyper, der ikke er eksplicit specificeret af andre direktiver. Det er et godt udgangspunkt for en grundlæggende CSP-politik. Hvis et mere specifikt direktiv som script-src er defineret, tilsidesætter det default-src-direktivet for scripts.
• script-src: Specificerer de tilladte kilder for JavaScript. Dette er et af de vigtigste direktiver til at forhindre XSS-angreb.
• style-src: Specificerer de tilladte kilder for CSS-stylesheets.
• img-src: Specificerer de tilladte kilder for billeder.
• font-src: Specificerer de tilladte kilder for skrifttyper.
• media-src: Specificerer de tilladte kilder for <audio>-, <video>- og <track>-elementer.
• object-src: Specificerer de tilladte kilder for <object>-, <embed>- og <applet>-elementer. Bemærk: Disse elementer er ofte en kilde til sikkerhedssårbarheder, og det anbefales at indstille dette til 'none' hvis muligt.
• frame-src: Specificerer de tilladte kilder for <iframe>-elementer.
• connect-src: Specificerer de tilladte kilder for XMLHttpRequest-, WebSocket- og EventSource-forbindelser. Dette er afgørende for at kontrollere, hvor din hjemmeside kan sende data.
• base-uri: Specificerer den tilladte base-URL for dokumentet.
• form-action: Specificerer de tilladte URL'er, som formularer kan sendes til.
• frame-ancestors: Specificerer de tilladte kilder, der kan indlejre den aktuelle side i en <frame>, <iframe>, <object> eller <applet>. Dette bruges til at forhindre clickjacking-angreb.
• upgrade-insecure-requests: Instruerer browseren til automatisk at opgradere alle usikre (HTTP) anmodninger til sikre (HTTPS) anmodninger. Dette er vigtigt for at sikre, at alle data overføres sikkert.
• block-all-mixed-content: Forhindrer browseren i at indlæse ressourcer over HTTP, når siden er indlæst over HTTPS. Dette er en mere aggressiv version af upgrade-insecure-requests.
• report-uri: Specificerer en URL, som browseren skal sende overtrædelsesrapporter til. Dette giver dig mulighed for at overvåge og finjustere din CSP-politik. *Udfaset, erstattet af `report-to`*
• report-to: Specificerer et gruppenavn defineret i `Report-To` HTTP-headeren, hvortil browseren skal sende overtrædelsesrapporter. Dette direktiv kræver, at `Report-To`-headeren er konfigureret korrekt.
• require-trusted-types-for: Aktiverer Trusted Types, et DOM API, der hjælper med at forhindre DOM-baserede XSS-sårbarheder. Kræver specifikke Trusted Types-implementeringer og konfigurationer.
• trusted-types: Definerer en liste over Trusted Types-politikker, der har lov til at oprette sinks.

Nøgleord for kildelister

Udover URL'er kan CSP-direktiver bruge flere nøgleord til at definere tilladte kilder:

• 'self': Tillader indhold fra samme oprindelse (skema og domæne) som det beskyttede dokument.
• 'unsafe-inline': Tillader brugen af inline JavaScript og CSS. Brug med ekstrem forsigtighed, da det svækker CSP markant og kan genintroducere XSS-sårbarheder. Undgå om muligt.
• 'unsafe-eval': Tillader brugen af dynamiske JavaScript-evalueringsfunktioner som eval() og Function(). Brug også med forsigtighed, da det svækker CSP. Overvej alternativer som template literals.
• 'unsafe-hashes': Tillader specifikke inline event-handlere ved at hvidliste deres SHA256-, SHA384- eller SHA512-hashes. Nyttigt for at overgå til CSP uden at skulle omskrive alle inline event-handlere med det samme.
• 'none': Tillader ikke indhold fra nogen kilde.
• 'strict-dynamic': Tillader scripts, der er indlæst af betroede scripts, at indlæse yderligere scripts, selvom disse scripts normalt ikke ville være tilladt af politikken. Nyttigt for moderne JavaScript-frameworks.
• 'report-sample': Instruerer browseren til at inkludere et eksempel på den overtrædende kode i overtrædelsesrapporten. Nyttigt til fejlfinding af CSP-problemer.
• data:: Tillader indlæsning af ressourcer fra data:-URL'er (f.eks. indlejrede billeder). Brug med forsigtighed.
• mediastream:: Tillader indlæsning af ressourcer fra mediastream:-URL'er (f.eks. webcam eller mikrofon).
• blob:: Tillader indlæsning af ressourcer fra blob:-URL'er (f.eks. dynamisk oprettede objekter).
• filesystem:: Tillader indlæsning af ressourcer fra filesystem:-URL'er (f.eks. adgang til lokalt filsystem).

Implementering af CSP: Praktiske eksempler

Der er to primære måder at implementere CSP på:

1. HTTP Response Header: Dette er den anbefalede tilgang, da den giver større fleksibilitet og kontrol.
2. <meta>-tag: Dette er en enklere tilgang, men den har begrænsninger (f.eks. kan den ikke bruges med frame-ancestors).

Eksempel 1: HTTP Response Header

For at indstille CSP-headeren skal du konfigurere din webserver (f.eks. Apache, Nginx, IIS). Den specifikke konfiguration afhænger af din serversoftware.

Her er et eksempel på en CSP-header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Forklaring:

• default-src 'self': Tillader som standard ressourcer fra samme oprindelse.
• script-src 'self' https://example.com: Tillader JavaScript fra samme oprindelse og fra https://example.com.
• style-src 'self' 'unsafe-inline': Tillader CSS fra samme oprindelse og inline styles (brug med forsigtighed).
• img-src 'self' data:: Tillader billeder fra samme oprindelse og data-URL'er.
• report-uri /csp-report: Sender overtrædelsesrapporter til /csp-report-endepunktet på din server.

Eksempel 2: <meta>-tag

Du kan også bruge et <meta>-tag til at definere en CSP-politik:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:">

Bemærk: Tilgangen med <meta>-tag har begrænsninger. For eksempel kan den ikke bruges til at definere frame-ancestors-direktivet, som er vigtigt for at forhindre clickjacking-angreb.

CSP i Report-Only-tilstand

Før du håndhæver en CSP-politik, anbefales det kraftigt at teste den i report-only-tilstand. Dette giver dig mulighed for at overvåge overtrædelser uden at blokere nogen ressourcer.

For at aktivere report-only-tilstand skal du bruge Content-Security-Policy-Report-Only-headeren i stedet for Content-Security-Policy:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-uri /csp-report

I report-only-tilstand vil browseren sende overtrædelsesrapporter til den specificerede URL, men den vil ikke blokere nogen ressourcer. Dette giver dig mulighed for at identificere og rette eventuelle problemer med din politik, før du håndhæver den.

Opsætning af Report URI-endepunkt

report-uri-direktivet (udfaset, brug `report-to`) specificerer en URL, som browseren skal sende overtrædelsesrapporter til. Du skal oprette et endepunkt på din server for at modtage og behandle disse rapporter. Disse rapporter sendes som JSON-data i body'en på en POST-anmodning.

Her er et forenklet eksempel på, hvordan du kan håndtere CSP-rapporter i Node.js:

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;

app.use(bodyParser.json({ type: 'application/csp-report' }));

app.post('/csp-report', (req, res) => {
 console.log('CSP Violation Report:', JSON.stringify(req.body, null, 2));
 res.status(204).end(); // Svar med 204 No Content
});

app.listen(port, () => {
 console.log(`CSP report server listening at http://localhost:${port}`);
});

Denne kode opretter en simpel server, der lytter efter POST-anmodninger til /csp-report-endepunktet. Når en rapport modtages, logger den rapporten til konsollen. I en virkelig applikation ville du sandsynligvis ønske at gemme disse rapporter i en database til analyse.

Når du bruger `report-to`, skal du også konfigurere `Report-To` HTTP-headeren. Denne header definerer rapporteringsendepunkterne og deres egenskaber.

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}],"include_subdomains":true}

Derefter ville du i din CSP-header bruge:

Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

Bedste praksis for CSP

Her er nogle bedste praksis, du bør følge, når du implementerer CSP:

• Start med en streng politik: Begynd med en restriktiv politik og løsn den gradvist efter behov. Dette vil hjælpe dig med at identificere og adressere potentielle sikkerhedssårbarheder tidligt.
• Brug nonces eller hashes til inline scripts og styles: Hvis du er nødt til at bruge inline scripts eller styles, skal du bruge nonces (kryptografisk tilfældige værdier) eller hashes til at hvidliste specifikke kodeblokke. Dette er mere sikkert end at bruge 'unsafe-inline'.
• Undgå 'unsafe-eval': 'unsafe-eval'-direktivet tillader brugen af dynamiske JavaScript-evalueringsfunktioner, hvilket kan udgøre en stor sikkerhedsrisiko. Undgå at bruge dette direktiv, hvis det er muligt. Overvej at bruge template literals eller andre alternativer.
• Brug HTTPS til alle ressourcer: Sørg for, at alle ressourcer indlæses over HTTPS for at forhindre man-in-the-middle-angreb. Brug upgrade-insecure-requests-direktivet til automatisk at opgradere usikre anmodninger.
• Overvåg og finjuster din politik: Overvåg regelmæssigt CSP-overtrædelsesrapporter og finjuster din politik efter behov. Dette vil hjælpe dig med at identificere og løse eventuelle problemer og sikre, at din politik forbliver effektiv.
• Overvej at bruge en CSP-generator: Flere onlineværktøjer kan hjælpe dig med at generere en CSP-politik baseret på din hjemmesides krav. Disse værktøjer kan forenkle processen med at skabe en stærk og effektiv politik.
• Test grundigt: Før du håndhæver din CSP-politik, skal du teste den grundigt i report-only-tilstand for at sikre, at den ikke ødelægger nogen funktionalitet på din hjemmeside.
• Brug et framework eller bibliotek: Nogle webudviklings-frameworks og biblioteker tilbyder indbygget understøttelse af CSP. Brug af disse værktøjer kan forenkle processen med at implementere og administrere din CSP-politik.
• Vær opmærksom på browserkompatibilitet: CSP understøttes af de fleste moderne browsere, men der kan være nogle kompatibilitetsproblemer med ældre browsere. Sørg for at teste din politik i en række forskellige browsere for at sikre, at den fungerer som forventet.
• Uddan dit team: Sørg for, at dit udviklingsteam forstår vigtigheden af CSP og hvordan man implementerer det korrekt. Dette vil hjælpe med at sikre, at CSP implementeres og vedligeholdes korrekt gennem hele udviklingslivscyklussen.

CSP og tredjepartsscripts

En af de største udfordringer ved implementering af CSP er at håndtere tredjepartsscripts. Mange hjemmesider er afhængige af tredjepartstjenester til analyse, annoncering og anden funktionalitet. Disse scripts kan introducere sikkerhedssårbarheder, hvis de ikke håndteres korrekt.

Her er nogle tips til at håndtere tredjepartsscripts med CSP:

• Brug Subresource Integrity (SRI): SRI giver dig mulighed for at verificere, at tredjepartsscripts ikke er blevet manipuleret. Når du inkluderer et tredjepartsscript, skal du inkludere integrity-attributten med scriptets hash. Browseren vil derefter verificere, at scriptet matcher hashen, før det udføres.
• Host tredjepartsscripts lokalt: Hvis det er muligt, host tredjepartsscripts lokalt på din egen server. Dette giver dig mere kontrol over scriptsene og reducerer risikoen for, at de bliver kompromitteret.
• Brug et Content Delivery Network (CDN) med CSP-support: Nogle CDN'er tilbyder indbygget support til CSP. Dette kan forenkle processen med at implementere og administrere CSP for tredjepartsscripts.
• Begræns tredjepartsscripts' tilladelser: Brug CSP til at begrænse tredjepartsscripts' tilladelser. For eksempel kan du forhindre dem i at få adgang til følsomme data eller lave anmodninger til uautoriserede domæner.
• Gennemgå regelmæssigt tredjepartsscripts: Gennemgå regelmæssigt de tredjepartsscripts, du bruger på din hjemmeside, for at sikre, at de stadig er sikre og pålidelige.

Avancerede CSP-teknikker

Når du har en grundlæggende CSP-politik på plads, kan du udforske nogle avancerede teknikker for yderligere at forbedre din hjemmesides sikkerhed:

• Brug af nonces til inline scripts og styles: Som tidligere nævnt er nonces kryptografisk tilfældige værdier, som du kan bruge til at hvidliste specifikke blokke af inline-kode. For at bruge nonces skal du generere en unik nonce for hver anmodning og inkludere den i både CSP-headeren og inline-koden.
• Brug af hashes til inline event-handlere: 'unsafe-hashes'-direktivet giver dig mulighed for at hvidliste specifikke inline event-handlere ved hjælp af deres SHA256-, SHA384- eller SHA512-hashes. Dette kan være nyttigt for at overgå til CSP uden at skulle omskrive alle inline event-handlere med det samme.
• Brug af Trusted Types: Trusted Types er et DOM API, der hjælper med at forhindre DOM-baserede XSS-sårbarheder. Det giver dig mulighed for at oprette specielle typer objekter, der garanteres at være sikre at bruge i visse sammenhænge.
• Brug af Feature Policy: Feature Policy (nu Permissions Policy) giver dig mulighed for at kontrollere, hvilke browserfunktioner der er tilgængelige for din hjemmeside. Dette kan hjælpe med at forhindre visse typer angreb og forbedre din hjemmesides ydeevne.
• Brug af Subresource Integrity (SRI) med fallback: Kombiner SRI med en fallback-mekanisme. Hvis SRI-tjekket fejler (f.eks. fordi CDN'et er nede), skal du have en backup-kopi af ressourcen hostet på din egen server.
• Dynamisk CSP-generering: Generer din CSP dynamisk på serversiden baseret på brugerens session, roller eller anden kontekstuel information.
• CSP og WebSockets: Når du bruger WebSockets, skal du omhyggeligt konfigurere connect-src-direktivet til kun at tillade forbindelser til betroede WebSocket-endepunkter.

Globale overvejelser ved implementering af CSP

Når du implementerer CSP for et globalt publikum, skal du overveje følgende:

• CDN-placeringer: Sørg for, at dit Content Delivery Network (CDN) har servere på flere geografiske steder for at levere hurtigt og pålideligt indhold til brugere over hele verden. Bekræft, at dit CDN understøtter CSP og kan håndtere de nødvendige headers.
• Globale regulativer: Vær opmærksom på databeskyttelsesregler som GDPR (Europa), CCPA (Californien) og andre regionale love. Sørg for, at din CSP-implementering overholder disse regler, især når du håndterer overtrædelsesrapporter.
• Lokalisering: Overvej, hvordan CSP kan påvirke lokaliseret indhold. Hvis du har forskellige scripts eller styles for forskellige sprog eller regioner, skal du sikre, at din CSP-politik imødekommer disse variationer.
• Internationaliserede domænenavne (IDN'er): Hvis din hjemmeside bruger IDN'er, skal du sikre, at din CSP-politik håndterer disse domæner korrekt. Vær opmærksom på potentielle kodningsproblemer eller browser-inkonsistenser.
• Cross-Origin Resource Sharing (CORS): CSP arbejder sammen med CORS. Hvis du foretager cross-origin anmodninger, skal du sikre, at din CORS-konfiguration er kompatibel med din CSP-politik.
• Regionale sikkerhedsstandarder: Nogle regioner kan have specifikke sikkerhedsstandarder eller krav. Undersøg og overhold disse standarder, når du implementerer CSP for brugere i disse regioner.
• Kulturelle overvejelser: Vær opmærksom på kulturelle forskelle i, hvordan hjemmesider bruges og tilgås. Tilpas din CSP-implementering for at imødekomme potentielle sikkerhedsrisici, der er specifikke for visse regioner eller demografier.
• Tilgængelighed: Sørg for, at din CSP-implementering ikke påvirker din hjemmesides tilgængelighed negativt. For eksempel må du ikke blokere nødvendige scripts eller styles, der kræves til skærmlæsere eller andre hjælpeteknologier.
• Test på tværs af regioner: Test din CSP-implementering grundigt på tværs af forskellige geografiske regioner og browsere for at identificere og løse eventuelle potentielle problemer.

Fejlfinding af CSP

Implementering af CSP kan undertiden være udfordrende, og du kan støde på problemer. Her er nogle almindelige problemer og hvordan man fejlfinder dem:

• Hjemmesiden går i stykker efter aktivering af CSP: Dette skyldes ofte en politik, der er for restriktiv. Brug browserens udviklerværktøjer til at identificere de ressourcer, der bliver blokeret, og juster din politik i overensstemmelse hermed.
• CSP-overtrædelsesrapporter modtages ikke: Kontroller din serverkonfiguration for at sikre, at report-uri (eller `report-to`)-endepunktet er konfigureret korrekt, og at din server håndterer POST-anmodninger korrekt. Bekræft også, at browseren rent faktisk sender rapporterne (du kan bruge udviklerværktøjerne til at tjekke netværkstrafikken).
• Vanskeligheder med inline scripts og styles: Hvis du har problemer med inline scripts og styles, kan du overveje at bruge nonces или hashes til at hvidliste dem. Alternativt kan du prøve at flytte koden til eksterne filer.
• Problemer med tredjepartsscripts: Brug SRI til at verificere integriteten af tredjepartsscripts. Hvis du stadig har problemer, kan du prøve at hoste scriptsene lokalt eller kontakte tredjepartsudbyderen for at få hjælp.
• Browserkompatibilitetsproblemer: CSP understøttes af de fleste moderne browsere, men der kan være nogle kompatibilitetsproblemer med ældre browsere. Test din politik i en række forskellige browsere for at sikre, at den fungerer som forventet.
• CSP-politiskonflikter: Hvis du bruger flere CSP-politikker (f.eks. fra forskellige plugins eller udvidelser), kan de komme i konflikt med hinanden. Prøv at deaktivere plugins eller udvidelser for at se, om det løser problemet.

Konklusion

Content Security Policy er et kraftfuldt værktøj til at forbedre din hjemmesides sikkerhed og beskytte dine brugere mod forskellige trusler. Ved at implementere CSP korrekt og følge bedste praksis kan du markant reducere risikoen for XSS-angreb, clickjacking og andre sårbarheder. Selvom implementering af CSP kan være kompleks, er de fordele, det giver i form af sikkerhed og brugertillid, anstrengelserne værd. Husk at starte med en streng politik, teste grundigt og løbende overvåge og finjustere din politik for at sikre, at den forbliver effektiv. I takt med at internettet udvikler sig og nye trusler opstår, vil CSP fortsat være en essentiel del af en omfattende websikkerhedsstrategi.